Apparatus and method for processing web service descriptions

ABSTRACT

An apparatus and method for processing a web service description such that the web service description is adapted for use with mobile devices. A web services accelerator is adapted to receive a web service description that defines an interface to a web service, create at least one accelerator output file from the web service description, and transmit the at least one accelerator output file to a mobile device. Accelerator output files are used by the mobile device to invoke web services.

FIELD OF THE INVENTION

Embodiments of the invention relate generally to web services, and morespecifically to the application of web services to mobile devices.

BACKGROUND OF THE INVENTION

A web service can be generally defined as one or more applicationfunctions that can be invoked over the Internet using a protocol. Oneexample of a protocol that may be used in this context is the SimpleObject Access Protocol (SOAP), which may be used by Internet-basedapplication servers, also known as web servers, to provide web services.SOAP is a protocol that is often used in the exchange of information indecentralized, distributed network environments.

One goal of web services is to use the infrastructure of the web toprovide information that is machine-readable. Unlike traditionalclient/server models such as a web server/web page system, web servicesdo not typically provide the user with a graphical user interface (GUI),but instead share business logic, data, and processes through aprogrammatic interface across a network. As applications are capable ofinterfacing with web services, developers may add web services to a GUI(e.g. a web page or executable program) to offer specific functionalityto users.

Furthermore, different applications from different sources cancommunicate with each other without extensive custom coding, and webservices are not associated with any one operating system or programminglanguages. This flexibility allows more sophisticatedbusiness-to-business applications as well as more sophisticated browsingmodels (with more client-side processing of data) to be developed.

However, despite an increase in popularity of the web services model,attempts to adapt the model specifically for use in the field ofwireless communications and by mobile devices have been relativelylimited. Given the various constraints that may be particular to mobiledevices (e.g. limited memory, increased bandwidth costs, etc.), there isa need to enhance the standard web services paradigm in a manner thatbetter accounts for these constraints while preserving many of theadvantages associated with web services.

SUMMARY OF THE INVENTION

Embodiments of the invention relate generally to web services, and morespecifically to the application of web services to mobile devices.

In one broad aspect of the invention, there is provided a web servicesaccelerator programmed to: receive a web service description thatdefines an interface to a web service, create at least one acceleratoroutput file adapted for processing by a mobile device from the webservice description, and transmit the at least one accelerator outputfile to the mobile device. The at least one accelerator output filefacilitates invocations of the web service by the mobile device.

The web services accelerator may reside on a computing device remotelycoupled to the mobile device in a network. Tasks related to theprocessing of a web service description by the web services accelerator,and other tasks including, for example, those relating to invocations ofweb services, may be performed on the remote computing device in orderto reduce the processing load on the mobile device.

In one embodiment of the invention, the at least one accelerator outputfile represents a version of the web service description that has beenoptimized for processing by the mobile device. Typically, the optimizedweb service description will be more compact in size, and can be moreefficiently transmitted to and subsequently processed by the mobiledevice.

In another embodiment of the invention, a subset of elements in the webservice description is sent to the device. This subset is the minimalamount of information required to describe the parameters of the webservice. Information required to invoke the web service, such aslocation and method, are stored in the web services accelerator.Parameter information received from the mobile device is passed back tothe web services accelerator and recombined with the invocationinformation. This technique typically reduces the amount of informationthat is required to be transferred to and from the mobile device.

In another embodiment of the invention, the at least one acceleratoroutput file represents executable code for the mobile device. The codecomprises instructions for obtaining input data, typically from a userof the mobile device, which is then used to invoke the web service. Inthis embodiment, client applications programmed to process web servicedescriptions for web services are not required for execution on themobile device itself.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features of embodiments of the invention will be madeapparent from the following description, with reference to theaccompanying drawings, in which:

FIG. 1 is a block diagram which illustrates components of a mobiledevice which communicates within a wireless communication network;

FIG. 2 is a schematic diagram illustrating components of the mobiledevice of FIG. 1;

FIG. 3 is a particular structure of a system for communication with themobile device;

FIG. 4A is a schematic diagram that illustrates a mobile deviceconnected to a web server over a connection in a wireless communicationnetwork;

FIG. 4B is a schematic diagram illustrating a web services acceleratorconnected to the web server and the mobile device of FIG. 4A;

FIG. 5 is a flowchart illustrating a method of processing a web servicedescription in an embodiment of the invention;

FIG. 6 is a flowchart illustrating a method of processing a web servicedescription in another embodiment of the invention;

FIG. 7 is a flowchart illustrating a method of processing a web servicedescription in another embodiment of the invention; and

FIG. 8 is a logical flow diagram illustrating a process of automaticallygenerating code in an embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

FIG. 1 is a block diagram of a communication system 100, which includesa mobile device 102 that communicates through a wireless communicationnetwork 104. Mobile device 102 preferably includes a visual display 112,a keyboard 114, and perhaps one or more auxiliary user interfaces (UI)116, each of which is coupled to a controller 106. Controller 106 isalso coupled to radio frequency (RF) transceiver circuitry 108 and anantenna 110.

Typically, controller 106 is embodied as a central processing unit(CPU), which runs operating system software in a memory component (notshown). Controller 106 will normally control overall operation of mobiledevice 102, whereas signal processing operations associated withcommunication functions are typically performed in RF transceivercircuitry 108. Controller 106 interfaces with device display 112 todisplay received information, stored information, user inputs, and thelike. Keyboard 114, which may be a telephone type keypad or fullalphanumeric keyboard, is normally provided for entering data forstorage in mobile device 102, information for transmission to network104, a telephone number to place a telephone call, commands to beexecuted on mobile device 102, and possibly other or different userinputs.

Mobile device 102 sends communication signals to and receivescommunication signals from network 104 over a wireless link via antenna110. RF transceiver circuitry 108 performs functions such asmodulation/demodulation and possibly encoding/decoding andencryption/decryption. It will be apparent to those skilled in art thatRF transceiver circuitry 108 will be adapted to particular wirelessnetwork or networks in which mobile device 102 is intended to operate.

Mobile device 102 includes a battery interface 134 for receiving one ormore rechargeable batteries 132. Battery 132 provides electrical powerto electrical circuitry in mobile device 102, and battery interface 132provides for a mechanical and electrical connection for battery 132.Battery interface 132 is coupled to a regulator 136, which regulatespower to the device. When mobile device 102 is fully operational, an RFtransmitter of RF transceiver circuitry 108 is typically keyed or turnedon only when it is sending to a network, and is otherwise turned off toconserve resources. Similarly, an RF receiver of RF transceivercircuitry 108 is typically periodically turned off to conserve poweruntil it is needed to receive signals or information (if at all) duringdesignated time periods.

Mobile device 102 operates using a Subscriber Identity Module (SIM) 140which is connected to or inserted in mobile device 102 at a SIMinterface 142. SIM 140 is one type of a conventional “smart card” usedto identify an end user (or subscriber) of mobile device 102 and topersonalize the device, among other things. Without SIM 140, the mobiledevice terminal is not fully operational for communication throughwireless network 104. By inserting SIM 140 into mobile device 102, anend user can have access to any and all of his/her subscribed services.SIM 140 generally includes a processor and memory for storinginformation. Since SIM 140 is coupled to SIM interface 142, it iscoupled to controller 106 through communication lines 144. In order toidentify the subscriber, SIM 140 contains some user parameters such asan International Mobile Subscriber Identity (IMSI). An advantage ofusing SIM 140 is that end users are not necessarily bound by any singlephysical mobile device. SIM 140 may store additional user informationfor the mobile device as well, including datebook (or calendar)information and recent call information.

Mobile device 102 may consist of a single unit, such as a datacommunication device, a cellular telephone, a multiple-functioncommunication device with data and voice communication capabilities, apersonal digital assistant (PDA) enabled for wireless communication, ora computer incorporating an internal modem. Alternatively, mobile device102 may be a multiple-module unit comprising a plurality of separatecomponents, including but in no way limited to a computer or otherdevice connected to a wireless modem. In particular, for example, in themobile device block diagram of FIG. 1, RF transceiver circuitry 108 andantenna 110 may be implemented as a radio modem unit that may beinserted into a port on a laptop computer: In this case, the laptopcomputer would include display 112, keyboard 114, one or more auxiliaryUIs 116, and controller 106 embodied as the computer's CPU. It is alsocontemplated that a computer or other equipment not normally capable ofwireless communication may be adapted to connect to and effectivelyassume control of RF transceiver circuitry 108 and antenna 110 of asingle-unit device such as one of those described above. Such a mobiledevice 102 may have a more particular implementation as described laterin relation to mobile device 202 of FIG. 2.

Mobile device 102 communicates in and through wireless communicationnetwork 104. In the embodiment of FIG. 1, wireless network 104 isconfigured in accordance with General Packet Radio Service (GPRS) and aGlobal Systems for Mobile (GSM) technologies. Wireless network 104includes a base station controller (BSC) 120 with an associated towerstation 118, a Mobile Switching Center (MSC) 122, a Home LocationRegister (HLR) 132, a Serving General Packet Radio Service (GPRS)Support Node (SGSN) 126, and a Gateway GPRS Support Node (GGSN) 128. MSC122 is coupled to BSC 120 and to a landline network, such as a PublicSwitched Telephone Network (PSTN) 124. SGSN 126 is coupled to BSC 120and to GGSN 128, which is in turn coupled to a public or private datanetwork 130 (such as the Internet). HLR 132 is coupled to MSC 122, SGSN126, and GGSN 128.

Station 118 is a fixed transceiver station, and station 118 and BSC 120are together referred to herein as the fixed transceiver equipment. Thefixed transceiver equipment provides wireless network coverage for aparticular coverage area commonly referred to as a “cell”. The fixedtransceiver equipment transmits communication signals to and receivescommunication signals from mobile devices within its cell via station118. The fixed transceiver equipment normally performs such functions asmodulation and possibly encoding and/or encryption of signals to betransmitted to the mobile device in accordance with particular, usuallypredetermined, communication protocols and parameters, under control ofits controller. The fixed transceiver equipment similarly demodulatesand possibly decodes and decrypts, if necessary, any communicationsignals received from mobile device 102 within its cell. Communicationprotocols and parameters may vary between different networks. Forexample, one network may employ a different modulation scheme andoperate at different frequencies than other networks.

The wireless link 150 of FIG. 1 represents one or more differentchannels, typically different radio frequency (RF) channels, andassociated protocols used between wireless network 104 and mobile device102. An RF channel is a limited resource that must be conserved,typically due to limits in overall bandwidth and a limited battery powerof mobile device 102. Those skilled in art will appreciate that awireless network in actual practice may include hundreds of cells, eachserved by a station 118 (or station sector), depending upon desiredoverall expanse of network coverage. All pertinent components may beconnected by multiple switches and routers (not shown), controlled bymultiple network controllers.

For all mobile devices 102 registered with a network operator, permanentdata (such as mobile device 102 user's profile) as well as temporarydata (such as mobile device's 102 current location) are stored in HLR132. In case of a voice call to mobile device 102, HLR 132 is queried todetermine the current location of mobile device 102. A Visitor LocationRegister (VLR) of MSC 122 is responsible for a group of location areasand stores the data of those mobile devices that are currently in itsarea of responsibility. This includes parts of the permanent mobiledevice data that have been transmitted from HLR 132 to the VLR forfaster access. However, the VLR of MSC 122 may also assign and storelocal data, such as temporary identifications. Optionally, the VLR ofMSC 122 can be enhanced for more efficient co-ordination of GPRS andnon-GPRS services and functionality (e.g. paging for circuit-switchedcalls which can be performed more efficiently via SGSN 126, and combinedGPRS and non-GPRS location updates).

Serving GPRS Support Node (SGSN) 126 is at the same hierarchical levelas MSC 122 and keeps track of the individual locations of mobiledevices. SGSN 126 also performs security functions and access control.Gateway GPRS Support Node (GGSN) 128 provides interworking with externalpacket-switched networks and is connected with SGSNs (such as SGSN 126)via an IP-based GPRS backbone network. SGSN 126 performs authenticationand cipher setting procedures based on the same algorithms, keys, andcriteria as in existing GSM. In conventional operation, cell selectionmay be performed autonomously by mobile device 102 or by the fixedtransceiver equipment instructing mobile device 102 to select aparticular cell. Mobile device 102 informs wireless network 104 when itreselects another cell or group of cells, known as a routing area.

In order to access GPRS services, mobile device 102 first makes itspresence known to wireless network 104 by performing what is known as aGPRS “attach”. This operation establishes a logical link between mobiledevice 102 and SGSN 126 and makes mobile device 102 available toreceive, for example, pages via SGSN, notifications of incoming GPRSdata, or SMS messages over GPRS. In order to send and receive GPRS data,mobile device 102 assists in activating the packet data address that itwants to use. This operation makes mobile device 102 known to GGSN 128;interworking with external data networks can thereafter commence. Userdata may be transferred transparently between mobile device 102 and theexternal data networks using, for example, encapsulation and tunneling.Data packets are equipped with GPRS-specific protocol information andtransferred between mobile device 102 and GGSN 128.

Those skilled in art will appreciate that a wireless network may beconnected to other systems, possibly including other networks, notexplicitly shown in FIG. 1. A network will normally be transmitting atvery least some sort of paging and system information on an ongoingbasis, even if there is no actual packet data exchanged. Although thenetwork consists of many parts, these parts all work together to resultin certain behaviours at the wireless link.

FIG. 2 is a detailed block diagram of a mobile device 202 (e.g. mobiledevice 102 of FIG. 1). Mobile device 202 is preferably a two-waycommunication device having at least voice and advanced datacommunication capabilities, including the capability to communicate withother computer systems. Depending on the functionality provided bymobile device 202, it may be referred to as a data messaging device, atwo-way pager, a cellular telephone with data messaging capabilities, awireless Internet appliance, or a data communication device (with orwithout telephony capabilities). Mobile device 202 may communicate withany one of a plurality of fixed transceiver stations 200 within itsgeographic coverage area.

Mobile device 202 will normally incorporate a communication subsystem211, which includes a receiver 212, a transmitter 214, and associatedcomponents, such as one or more (preferably embedded or internal)antenna elements 216 and 218, local oscillators (LOs) 213, and aprocessing module such as a digital signal processor (DSP) 220.Communication subsystem 211 is analogous to RF transceiver circuitry 108and antenna 110 shown in FIG. 1. As will be apparent to those skilled infield of communications, particular design of communication subsystem211 depends on the communication network in which mobile device 202 isintended to operate.

Mobile device 202 may send and receive communication signals over thenetwork after required network registration or activation procedureshave been completed. Signals received by antenna 216 through the networkare input to receiver 212, which may perform such common receiverfunctions as signal amplification, frequency down conversion, filtering,channel selection, and like, and in example shown in FIG. 2,analog-to-digital (A/D) conversion. A/D conversion of a received signalallows more complex communication functions such as demodulation anddecoding to be performed in DSP 220. In a similar manner, signals to betransmitted are processed, including modulation and encoding, forexample, by DSP 220. These DSP-processed signals are input totransmitter 214 for digital-to-analog (D/A) conversion, frequency upconversion, filtering, amplification and transmission over communicationnetwork via antenna 218. DSP 220 not only processes communicationsignals, but also provides for receiver and transmitter control. Forexample, the gains applied to communication signals in receiver 212 andtransmitter 214 may be adaptively controlled through automatic gaincontrol algorithms implemented in DSP 220.

Network access is associated with a subscriber or user of mobile device202, and therefore mobile device 202 requires a Subscriber IdentityModule or “SIM” card 262 to be inserted in a SIM interface 264 in orderto operate in the network. SIM 262 includes those features described inrelation to FIG. 1. Mobile device 202 is a battery-powered device so italso includes a battery interface 254 for receiving one or morerechargeable batteries 256. Such a battery 256 provides electrical powerto most, if not all electrical circuitry in mobile device 202, andbattery interface 254 provides for a mechanical and electricalconnection for it. The battery interface 254 is coupled to a regulator(not shown), which provides power V+ to all of the circuitry.

Mobile device 202 includes a microprocessor 238 (which is oneimplementation of controller 106 of FIG. 1), which controls overalloperation of mobile device 202. Communication functions, including atleast data and voice communications, are performed through communicationsubsystem 211. Microprocessor 238 also interacts with additional devicesubsystems such as a display 222, a flash memory 224, a random accessmemory (RAM) 226, auxiliary input/output (I/O) subsystems 228, a serialport 230, a keyboard 232, a speaker 234, a microphone 236, a short-rangecommunications subsystem 240, and any other device subsystems generallydesignated at 242. Some of the subsystems shown in FIG. 2 performcommunication-related functions, whereas other subsystems may provide“resident” or on-device functions. Notably, some subsystems, such askeyboard 232 and display 222, for example, may be used for bothcommunication-related functions, such as entering a text message fortransmission over a communication network, and device-resident functionssuch as a calculator or task list. Operating system software used bymicroprocessor 238 is preferably stored in a persistent store such asflash memory 224, which may alternatively be a read-only memory (ROM) orsimilar storage element (not shown). Those skilled in the art willappreciate that the operating system, specific device applications, orparts thereof, may be temporarily loaded into a volatile store such asRAM 226.

Microprocessor 238, in addition to its operating system functions,preferably enables execution of software applications on mobile device202. A predetermined set of applications which control basic deviceoperations, including at least data and voice communication applications(such as a network reestablishment scheme), will normally be installedon mobile device 202 during its manufacture. A preferred applicationthat may be loaded onto mobile device 202 may be a personal informationmanager (PIM) application having the ability to organize and manage dataitems relating to user such as, but not limited to, e-mail, calendarevents, voice mails, appointments, and task items. Naturally, one ormore memory stores are available on mobile device 202 and SIM 256 tofacilitate storage of PIM data items and other information.

The PIM application preferably has the ability to send and receive dataitems via the wireless network. In a preferred embodiment, PIM dataitems are seamlessly integrated, synchronized, and updated via thewireless network, with the mobile device user's corresponding data itemsstored and/or associated with a host computer system thereby creating amirrored host computer on mobile device 202 with respect to such items.This is especially advantageous where the host computer system is themobile device user's office computer system. Additional applications mayalso be loaded onto mobile device 202 through the communicationsnetwork, an auxiliary I/O subsystem 228, serial port 230, short-rangecommunications subsystem 240, or any other suitable subsystem 242, andinstalled by a user in RAM 226 or preferably a non-volatile store (notshown) for execution by microprocessor 238. Such flexibility inapplication installation increases the functionality of mobile device202 and may provide enhanced on-device functions, communication-relatedfunctions, or both. For example, secure communication applications mayenable electronic commerce functions and other such financialtransactions to be performed using mobile device 202.

In a data communication mode, a received signal such as a text message,an e-mail message, or web page download will be processed bycommunication subsystem 211 and input to microprocessor 238.Microprocessor 238 will preferably further process the signal for outputto display 222 or alternatively to auxiliary I/O device 228. A user ofmobile device 202 may also compose data items, such as e-mail messages,for example, using keyboard 232 in conjunction with display 222 andpossibly auxiliary I/O device 228. Keyboard 232 is preferably a completealphanumeric keyboard and/or telephone-type keypad. These composed itemsmay be transmitted over a communication network through communicationsubsystem 211.

For voice communications, the overall operation of mobile device 202 issubstantially similar, except that the received signals would be outputto speaker 234 and signals for transmission would be generated bymicrophone 236. Alternative voice or audio I/O subsystems, such as avoice message recording subsystem, may also be implemented on mobiledevice 202. Although voice or audio signal output is preferablyaccomplished primarily through speaker 234, display 222 may also be usedto provide an indication of the identity of a calling party, duration ofa voice call, or other voice call related information, as some examples.

Serial port 230 in FIG. 2 is normally implemented in a personal digitalassistant (PDA)-type communication device for which synchronization witha user's desktop computer is a desirable, albeit optional, component.Serial port 230 enables a user to set preferences through an externaldevice or software application and extends the capabilities of mobiledevice 202 by providing for information or software downloads to mobiledevice 202 other than through a wireless communication network. Thealternate download path may, for example, be used to load an encryptionkey onto mobile device 202 through a direct and thus reliable andtrusted connection to thereby provide secure device communication.

Short-range communications subsystem 240 of FIG. 2 is an additionaloptional component which provides for communication between mobiledevice 202 and different systems or devices, which need not necessarilybe similar devices. For example, subsystem 240 may include an infrareddevice and associated circuits and components, or a Bluetooth™communication module to provide for communication with similarly-enabledsystems and devices. Bluetooth™ is a registered trademark of BluetoothSIG, Inc.

FIG. 3 shows an example system structure for communicating with a mobiledevice. In particular, FIG. 3 shows basic components of one example ofan IP-based wireless data network which may be utilized. Mobile device302 (e.g. mobile device 102 and 202 of FIG. 1 and FIG. 2 respectively)communicates with a wireless packet data network 305, and may also becapable of communicating with a wireless voice network (not shown). Asshown in FIG. 3, a gateway 310 may be coupled to an internal or externaladdress resolution component 315 and one or more network entry points320. Data packets are transmitted from gateway 310, which is a source ofinformation to be transmitted to mobile device 302, through network 305by setting up a wireless network tunnel 325 from gateway 310 to mobiledevice 302. In order to create this wireless tunnel 325, a uniquenetwork address is associated with mobile device 302. In an IP-basedwireless network, however, network addresses are typically notpermanently assigned to a particular mobile device 302 but instead aredynamically allocated on an as-needed basis. It is thus preferable formobile device 302 to acquire a network address and for gateway 310 todetermine this address so as to establish wireless tunnel 325.

Network entry point 320 is generally used to multiplex and demultiplexamongst many gateways, corporate servers, and bulk connections such asthe Internet, for example. There are normally very few of these networkentry points 320, since they are also intended to centralize externallyavailable wireless network services. Network entry points 320 often usesome form of an address resolution component 315 that assists in addressassignment and lookup between gateways and mobile devices. In thisexample, address resolution component 315 is shown as a dynamic hostconfiguration protocol (DHCP) as one method for providing an addressresolution mechanism.

A central internal component of wireless data network 305 is a networkrouter 330. Normally, network routers 330 are proprietary to theparticular network, but they could alternatively be constructed fromstandard commercially available hardware. The purpose of network routers330 is to centralize thousands of fixed transceiver stations 335normally implemented in a relatively large network into a centrallocation for a long-haul connection back to network entry point 320. Insome networks there may be multiple tiers of network routers 330 andcases where there are master and slave network routers 330, but in allsuch cases the functions are similar. Often a network router 330 willaccess a name server 340, in this case shown as a dynamic name server(DNS) 340 as used in the Internet, to look up destinations for routingdata messages. Fixed transceiver stations 335, as described above,provide wireless links to mobile devices such as mobile device 302.

Wireless network tunnels such as a wireless tunnel 325 are opened acrosswireless network 305 in order to allocate necessary memory, routing, andaddress resources to deliver IP packets. Such tunnels 325 areestablished as part of what are referred to as Packet Data Protocol or“PDP contexts” (i.e. data sessions). To open wireless tunnel 325, mobiledevice 302 must use a specific technique associated with wirelessnetwork 305. The step of opening such a wireless tunnel 325 may requiremobile device 302 to indicate the domain, or network entry point 320with which it wishes to open wireless tunnel 325. In this example, thetunnel first reaches network router 330 which uses name server 340 todetermine which network entry point 320 matches the domain provided.Multiple wireless tunnels can be opened from one mobile device 302 forredundancy, or to access different gateways and services on the network.Once the domain name is found, the tunnel is then extended to networkentry point 320 and necessary resources are allocated at each of thenodes along the way. Network entry point 320 then uses the addressresolution component 315 to allocate an IP address for mobile device302. When an IP address has been allocated to mobile device 302 andcommunicated to gateway 310, information can then be forwarded fromgateway 310 to mobile device 302.

Wireless tunnel 325 typically has a limited life, depending on mobiledevice's 302 coverage profile and activity. Wireless network 305 willtear down wireless tunnel 325 after a certain period of inactivity orout-of-coverage period, in order to recapture resources held by thiswireless tunnel 325 for other users. The main reason for this is toreclaim the IP address temporarily reserved for mobile device 302 whenwireless tunnel 325 was first opened. Once the IP address is lost andwireless tunnel 325 is torn down, gateway 310 loses all ability toinitiate IP data packets to mobile device 302, whether over TransmissionControl Protocol (TCP) or over User Datagram Protocol (UDP).

Referring to FIG. 4A, there is shown a schematic diagram thatillustrates a mobile device 202 connected to a web server 405 over aconnection 410 in a wireless data network (e.g. wireless network 305 ofFIG. 3). Web server 405 is a provider of web services. Generally, webservices are self-contained, self-describing modular applications thatcan be deployed (i.e. published), located, and invoked across the WorldWide Web (the “Web”). Other applications, including other web services,can discover deployed web services and invoke them.

A basic web service platform may be based on the Extensible MarkupLanguage (XML) and the Hyper Text Transfer Protocol (HTTP). XML providesa metalanguage in which specialized languages may be written to expresscomplex interactions between clients and services, or between componentsof a composite service. Web server 405 will typically convert XMLmessages into a middleware request, and convert results back into XML.

This basic platform is augmented with several other platform services toconstitute a more functional platform. A fully-functional web servicesplatform further consists of three additional elements: the SimpleObject Access Protocol (SOAP), the Universal Description, Discovery andIntegration Service (UDDI) [not shown], and the Web Services DescriptionLanguage (WSDL).

SOAP is a protocol specification that defines a uniform way of passingdata as an XML message. SOAP can be synchronous (e.g. a remote procedurecall) or asynchronous (e.g. a message). In particular, SOAP is oneexample of a protocol that may be used to encode the information in webservice requests and response messages before they are sent over anetwork.

UDDI is used for listing what web services are available, and provides amechanism for clients to dynamically find specific web services. It is aWeb-based distributed directory that enables web service publishers (whohave information or services to share) to register themselves, and forclients or web service consumers (who want information or services) tosearch these registries. When an appropriate web service has been found,a description of this service may be retrieved.

WSDL is a way to describe a web service. More specifically, WSDLprovides a way for web service providers to describe the basic format ofweb service requests over different protocols or encodings. WSDL is anXML description of a web service, which describes what the web servicecan do, where it resides, and how to invoke it.

In one embodiment of the invention, a web service description isembodied in a WSDL file. WSDL files include all the information neededto use a web service including the format of the message web server 405is expecting, and the location of web server 405 on a network.Furthermore, WSDL files can be converted into code which will invoke aweb service.

WSDL defines services as collections of network communication endpointsor ports capable of exchanging messages. In WSDL, the abstractdefinition of endpoints and messages is separated from their concretenetwork deployment or data format bindings. This allows the reuse ofabstract definitions of messages, which are abstract descriptions of thedata being exchanged, and port types, which are abstract collections ofoperations. The concrete protocol and data format specifications for aparticular port type constitute a reusable binding. A port is defined byassociating a network address with a reusable binding, and a collectionof ports defines a service. Accordingly, a WSDL document uses thefollowing elements (also referred to herein as web service descriptionelements):

-   -   Types:    -    a container for data type definitions using some type system        (e.g. XML Schema Definition or XSD);    -   Message:    -    an abstract, typed definition of the data being communicated;    -   Operation:    -    an abstract description of an action supported by the service;    -   Port Type:    -    an abstract set of operations supported by one or more        endpoints;    -   Binding:    -    a concrete protocol and data format specification for a        particular port type;    -   Port:    -    a single endpoint defined as a combination of a binding and a        network address; and    -   Service:    -    a collection of related endpoints.

While other protocols and message formats may be used to communicatewith a web service (e.g. HTTP GET/POST, Multipurpose Internet MailExtensions or MIME), an embodiment of the invention will now bedescribed in further detail herein assuming that SOAP is used as theinvocation protocol for communications between mobile device 202 and webserver 405.

Web service protocols and formats such as WSDL and SOAP were notinitially designed for specific adaptation to wireless communicationbetween web services and mobile devices. As a result, web servicedescriptions, which may be in the form of WSDL files for example, tendto be relatively verbose. In order to preserve bandwidth and moreefficiently support web services on mobile devices, a web servicesaccelerator may be used in accordance with an embodiment of theinvention.

Referring to FIG. 4B, a web services accelerator 415 is shown. Webservices accelerator 415 communicates with web server 405 and withmobile device 202. In one embodiment of the invention, web servicesaccelerator 415 is provided on a server which acts as a gateway (e.g.gateway 310 of FIG. 3) between web server 405 residing in a network(e.g. wireless network 305 of FIG. 3) and mobile device 202. In variantembodiments of the invention, web services accelerator 415 may reside ona different computing device or elsewhere in the network, including webserver 405 itself, for example.

Web services accelerator 415 outputs one or more files to mobile device202 for further processing. These files may then be used by mobiledevice 202 to invoke one or more desired web services.

Referring to FIG. 5, a flowchart illustrating a method of processing aweb service description so that the web service description is adaptedfor use with mobile device (e.g. mobile device 202 of FIG. 4B) in anembodiment of the invention is shown generally as 500.

In this embodiment of the invention, a web services accelerator (e.g.web services accelerator 415 of FIG. 4B) transforms standard web serviceprotocols coming from a web server (e.g. web server 405 of FIG. 4B) intoa wireless friendly form, in which the information that is required fora mobile device to consume a web service is minimized.

For example, a web service description in the form of a WSDL file may beoptimized for mobile devices by the web services accelerator, andtransmitted to the mobile device for subsequent use. Similarly, the webservices accelerator may be adapted to translate data received from themobile device into standard web service protocols. As the web servicesaccelerator is adapted to handle standard web service protocols,existing web services may be made compatible for use with mobiledevices, and a customized set of “wireless” web services need not beseparately offered by web service providers.

At step 510, a web service description file (i.e. a WSDL file in thisexample) associated with a web service is received by the web servicesaccelerator, as may be required to support one or more applications tobe executed on the mobile device, for example. The WSDL file may beobtained from a location identified on the UDDI registry, for example.Other registry methods can also be used to locate the appropriate WSDLfile including vendor specific registry protocols and human readable webbased systems. The web services accelerator is preferably located on aremote computing device coupled to the mobile device, thereby offloadingthe task of processing the received WSDL file from the mobile device.

At step 512, parsing of the WSDL file is commenced by the web servicesaccelerator, where symbolic references in the WSDL file are resolved ina forward direction to create an accelerator output file (i.e. anoptimized WSDL file in this example), such that all of these symbolicreferences may be subsequently processed or parsed by the mobile devicein a single pass. As standard WSDL has many symbolic references that mayrequire holding the entire WSDL file in a memory to parse it, thecreation of an optimized WSDL file that can be parsed in one passrequires less resources and processing on the mobile device. Forexample, step 512 may be facilitated by representing elements in theWSDL file as nodes in a graph, and reordering the nodes into a n-arytree data structure, with the service element at its root.

At step 514, elements in the WSDL file associated with transportprotocols not supported by the mobile device may also be optionally“deleted”, by not including them in creating the optimized WSDL file.For example, if the mobile device will invoke web services only throughSOAP calls, elements associated with other transport protocols will bedeleted in creating the optimized WSDL file. This may result in a morecompact accelerator output file that can be transmitted to the mobiledevice more quickly, and may require less memory to store.

At step 516, one or more names associated with elements in the WSDL filemay optionally be modified in creating the optimized WSDL file. Forexample, elements may be renamed to eliminate the use of namespaces,such that shorter names may be used. More generally, longer names ofelements may be replaced with shorter names. This may result in a morecompact accelerator output file that can be transmitted to the mobiledevice more quickly, and may require less memory to store.Alternatively, a binary encoding scheme such as WAP Binary XML (WBXML)could be employed to reduce the size of the file. WBXML files are binarytokenized equivalents of XML files.

At step 518, the optimized WSDL file created in the processing at steps512 through 516 by the web services accelerator of the WSDL filereceived at step 510 may be validated. Error handling and validationperformed at this step ensure that the optimized WSDL file is a validXML file, which can be subsequently parsed or processed by the mobiledevice. By performing this step before transmission of the validatedoptimized WSDL file to the mobile device, error handling and validationneed not be performed by the mobile device (where it may not beperformed as efficiently).

Alternatively, the WSDL file received at step 510 may be validatedbefore parsing (e.g. before step 512), to avoid the processing of aninvalid WSDL file.

At step 520, the optimized (and validated, if applicable) WSDL file istransmitted to the mobile device over a network connection.

At step 522, the optimized WSDL file is received by the mobile device,and processed by the mobile device by identifying the elements in thefile that define inputs to the web service, the destination server (i.e.web server) of the web service, and a format for the inputs.

At step 524, the mobile device invokes the web service, by transmittinginput data to the web service in the specified format. This step may befacilitated by receiving input data from a user of the mobile devicethrough the user interface of an application executing on the mobiledevice.

At step 526, the mobile device receives output data from the web servicein response to the invocation. The mobile device may then display theoutput data to a user of the mobile device through the user interface ofan application executing on the mobile device.

To illustrate this embodiment of the invention by way of an example,consider the following WSDL file:

<?xml version=“1.0” encoding=“UTF-8”?> <wsdl:definitionstargetNamespace=“http://rowen-websphere:8080/axis/Add.jws”xmlns=“http://schemas.xmlsoap.org/wsdl/”xmlns:apachesoap=“http://xml.apache.org/xml-soap”xmlns:impl=“http://rowen-websphere:8080/axis/Add.jws”xmlns:intf=“http://rowen-websphere:8080/axis/Add.jws”xmlns:soapenc=“http://schemas.xmlsoap.org/soap/encoding/”xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/”xmlns:wsdlsoap=“http://schemas.xmlsoap.org/wsdl/soap/”xmlns:xsd=“http://www.w3.org/2001/XMLSchema”><wsdl:types/> <wsdl:message name=“addRequest”>   <wsdl:part name=“a” type=“xsd:int”/>  <wsdl:part name=“b” type=“xsd:int”/>  </wsdl:message>  <wsdl:messagename=“addResponse”>   <wsdl:part name=“addReturn” type=“xsd:int”/> </wsdl:message>  <wsdl:portType name=“Add”>   <wsdl:operationname=“add” parameterOrder=“a b”>    <wsdl:inputmessage=“impl:addRequest” name=“addRequest”/>    <wsdl:outputmessage=“impl:addResponse” name=“addResponse”/>   </wsdl:operation> </wsdl:portType>  <wsdl:binding name=“AddSoapBinding” type=“impl:Add”>  <wsdlsoap:binding style=“rpc”transport=“http://schemas.xmlsoap.org/soap/http”/>   <wsdl:operationname=“add”>    <wsdlsoap:operation soapAction=“”/>    <wsdl:inputname=“addRequest”>     <wsdlsoap:bodyencodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”namespace=“http://rowen- websphere:8080/axis/Add.jws” use=“encoded”/>   </wsdl:input>    <wsdl:output name=“addResponse”>     <wsdlsoap:bodyencodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”namespace=“http://rowen- websphere:8080/axis/Add.jws” use=“encoded”/>   </wsdl:output>   </wsdl:operation>  </wsdl:binding>  <wsdl:servicename=“AddService”>   <wsdl:port binding=“impl:AddSoapBinding”name=“Add”>    <wsdlsoap:addresslocation=“http://rowen-websphere:8080/axis/Add.jws”/>   </wsdl:port> </wsdl:service> </wsdl:definitions>

After the web services accelerator processes the description inaccordance with an embodiment of the invention, the WSDL file may beconverted into the following optimized WSDL file, which may betransmitted to the mobile device for further processing:

<?xml version=“1.0” encoding=“UTF-8”?> <wsdl>     <tp xmlns=“”xmlns:soap=“http://schemas.xmlsoap.org/wsdl/     soap/”/>     <sxmlns=“” xmlns:soap=“http://schemas.xmlsoap.org/wsdl/ soap/”n=“AddService” a=“http://rowen-websphere:8080/axis/Add.jws”ns=“http://rowen-websphere:8080/axis/Add.jws” n=“Add”>         <opn=“add” x=“”>             <i>                 <p n=“a” t=“xsd:int”/>                <p n=“b” t=“xsd:int”/>             </i>             <o>                <p n=“addReturn” t=“xsd:int”/>             </o>        </op>     </s> </wsdl>

Referring to FIG. 6, a flowchart illustrating a method of processing aweb service description so that the web service description is adaptedfor use with mobile device (e.g. mobile device 202 of FIG. 4B) in anembodiment of the invention is shown generally as 600.

In this embodiment of the invention, a web services accelerator (e.g.web services accelerator 415 of FIG. 4B) transforms standard web serviceprotocols coming from a web server (e.g. web server 405 of FIG. 4B) intoa wireless friendly form, in which the information that is required fora mobile device to consume a web service is minimized. In contrast toFIG. 5, invocation information is extracted from a web servicedescription and retained by the web services accelerator. Informationassociated with a subsequent invocation of the web service is sent fromthe mobile device to the web services accelerator, and combined with theretained invocation information to be sent to the web service as a validweb service invocation. Results from the web services are returned tothe web services accelerator, which produces a wireless-optimizedmessage representing the result of the web service invocation fortransmission to the mobile device.

Steps 610, 612, and 614 provide the same function as steps 510, 512, and514 respectively in the description of FIG. 5.

At step 616, invocation information is extracted from the web servicedescription received at step 610. Such invocation information includesinformation required to invoke the web service, which may include thelocation of the web service and the invocation method, for example. Thisinvocation information is retained in the web services accelerator, andis not included in the creation of the optimized WSDL file to be sent tothe mobile device.

Step 618, 620 and 622 provide the same function as steps 516, 518, and520 respectively in the description of FIG. 5.

At step 624, the optimized WSDL file is received by the mobile device,and processed by the mobile device by identifying the elements in thefile that define parameters required for a web service invocation, suchas inputs to the web service, for example.

At step 626, the mobile device gathers operation parameters required toinvoke the web service, as defined in the optimized WSDL file. This stepmay be facilitated by receiving data from a user of the mobile devicethrough the user interface of an application executing on the mobiledevice.

At step 628, the operation parameters are transmitted by the mobiledevice to the web services accelerator.

At step 630, the operation parameters are combined with invocationinformation retained in the web services accelerator (e.g. at step 616)to generate input data for a web service invocation.

At step 632, the web services accelerator invokes the web service, bytransmitting the input data to the web service.

At step 634, the web services accelerator receives output data from theweb service in response to the invocation and transmits the output datato the mobile device. The mobile device may then display the output datato a user of the mobile device through the user interface of anapplication executing on the mobile device. The output data receivedfrom the web service may be optimized before it is sent to the mobiledevice, to reduce the amount of information that is transmitted to themobile device.

Referring to FIG. 7, a flowchart illustrating a method of processing aweb service description so that the web service description is adaptedfor use with mobile device (e.g. mobile device 202 of FIG. 4B) inanother embodiment of the invention is shown generally as 700.

In this embodiment of the invention, a web services accelerator (e.g.web services accelerator 415 of FIG. 4B) processes standard web serviceprotocols coming from a web server (e.g. web server 405 of FIG. 4B) bygenerating code in a native language of the mobile device, therebyeliminating the need for an additional parser.

For example, a web service description in the form of a WSDL file may beused to generate an executable application in the form of Java code,which may then be executed on a mobile device adapted to execute Javaapplications. Accordingly, the mobile device need not be adapted tounderstand the standard web service protocols, and web servicedescriptions need not be transmitted to or processed by the mobiledevice. As the web services accelerator is adapted to handle standardweb service protocols, existing web services may be made compatible foruse with mobile devices, and a customized set of “wireless” web servicesneed not be separately offered by web service providers.

Furthermore, in creating an accelerator output file in the form of anexecutable application, the application may also be programmed togenerate a user interface to be displayed on the mobile device. The userinterface may be used to obtain input data from the user of a mobiledevice to facilitate a web service invocation. The web servicesaccelerator may be adapted to translate data received from the mobiledevice through the user interface into standard web service protocols.Output from the web service may also be displayed to the user throughthe user interface.

At step 710, a web service description file (i.e. a WSDL file in thisexample) associated with a web service is received by the web servicesaccelerator as described with respect to step 510 of FIG. 5.

At step 712, parsing of the WSDL file is commenced by the web servicesaccelerator, where all operations defined in the file are determined.

At step 714, the name, type and other formatting information associatedwith inputs to the web services are identified for each operationdetermined at step 712.

At step 716, other information including the destination (e.g. the webserver) to which input data is to be sent when invoking the web service,and the format of the anticipated output by the web service, are alsoidentified from the web service description.

At step 718, in the form of an application to facilitate the invocationof a web service, instructions in the Java programming language aregenerated based on the information obtained at previous steps of method700. For example, the application may be programmed to display, in auser interface, entry fields to prompt a user for one or more of theinputs required to invoke the web service. The application will receiveinput data from a user of the mobile device, and checks the input datato confirm that they are of a valid type, as defined by the web servicedescription. The application may also be programmed to obtaininformation related to the state of the mobile device or the mobiledevice environment. For example, information on the device's locationmay be retrieved and returned to the web service. When all requisiteinputs have been received, the application may be programmed toautomatically invoke the web service by transmitting the input data tothe destination web server in the specified format.

At step 720, instructions may also be generated in the Java programminglanguage to receive output data from the web service, in the formatpreviously identified from the web service description, and to displaythe output data to a user in a user interface.

At step 722, the instructions produced at steps 718 and 720 are compiledinto an accelerator output file in the form of Java bytecode by a Javacompiler. Validation of the code may be integrated into this compilationstep.

In variant embodiments of the invention, Java bytecode or other objectcode may be generated directly, without requiring the generation ofinstructions and subsequent compilation of these instructions.

At step 724, the application associated with the web service in the formof Java bytecode is transmitted to the mobile device, which may then be“processed” by executing the Java bytecode.

From the perspective of a user of the mobile device, web serviceapplications may be downloaded upon request without requiring that acustomized “wireless” version be available, as it is not necessary for aprogrammer to create a user interface specific to a selected web servicewhere a web services accelerator is implemented. Accordingly, theinvention may facilitate the automatic generation of client code in someembodiments.

Referring to FIG. 8, there is shown a logical flow diagram illustratinga process of automatically generating code in an embodiment of theinvention in which a web services accelerator is adapted as a codegenerator (e.g. as described with reference to FIG. 6). The diagramillustrates the flow of data between a browser 800 operated by a user, aweb service directory 802, a web service 804 (provided by a web serviceprovider), and a web services accelerator 806, in an exampleimplementation of an embodiment of the invention.

At 810, a user of a mobile device that is equipped with a browser 800finds one or more web services through a web service directory 802.

At 812, information on one or more web services is returned to the userthrough browser 800.

At 814, the user may then select a specific web service 804 usinginformation received through browser 800.

At 816, a first request is made for the web service description of theselected web service 804 in the form of a WSDL file from the web serviceprovider.

At 818, a WSDL file associated with the selected web service 804 isreturned to the web services accelerator 806.

At 820, the web services accelerator 806 returns a Java ApplicationDescriptor (.jad) file associated with the selected web service to thebrowser 800.

At 822, the user is prompted to decide whether to download a Javaapplication associated with the selected web service 804.

At 824, the user accepts the download and an executable file (e.g. in aJava Archive (.jar) format) is requested by browser 800.

At 826, a second request is made for the web service description in theform of a WSDL file of the selected web service 804 from the web serviceprovider by the web services accelerator 806, to ensure that the webservice description being considered by the web services accelerator 806is current.

At 828, the WSDL file associated with the selected web service 804 isreturned to the web services accelerator 806.

At 830, an executable Java application is created by the web servicesaccelerator 806 (e.g. as described with reference to FIG. 7) andreturned to the user through browser 800. Confirmation of receipt of theapplication by the mobile device may be displayed to the user when thedownload is complete.

In variant embodiments of the invention, support for web services may beintegrated into a web browser of the mobile device. In theseembodiments, the web services accelerator may be adapted to produce abrowser plug-in module for supporting a particular web service, ratherthan a separate stand-alone application.

While the accelerator output file is in the form of an executable Javaapplication in one example implementation of this embodiment of theinvention, the accelerator output file may be based on differentlanguages or be of a different form in other implementations of theinvention.

Although the mobile device invokes the web service directly in theembodiment of the invention described with reference to the examples ofFIG. 5 and FIG. 7, in variant embodiments of the invention, the mobiledevice may instead invoke the web service indirectly by transmittinginformation (e.g. operation parameters) and/or a request to the webservices accelerator to invoke the web service, as described withreference to FIG. 6, for example. Where the web services accelerator isadapted to invoke the web service on behalf of the mobile device, theaccelerator output file created and transmitted by the web servicesaccelerator to the mobile device may be made even more compact, as themobile device will require even less information to initiate a webservice invocation.

Similarly, in variant embodiments of the invention, output from webservices may be received by the web services accelerator andretransmitted (with modifications, if desired) to the mobile device,rather than the output being received directly by the mobile device.Moreover, in variant embodiments of the invention, the web servicesaccelerator may be adapted to monitor one or more web services forchanges in the output, and to “push” such changes to the mobile device.By adapting the web services accelerator in this manner, synchronous“pull” operations may be converted into asynchronous “push” operations.Due to certain typical characteristics of wireless networks (e.g. lowbandwidth, intermittent connectivity), asynchronous applicationstypically provide for an improved user experience, when compared tosynchronous applications. When asynchronous applications are used, usersof a mobile device may access up-to-date data stored locally on themobile device, while being shielded from the effects of network latencyand bandwidth limitations. This feature may also be offered as asubscription to users, if desired.

In variant embodiments of the invention, the web services acceleratormay also perform processing on files or messages related to otherprotocols. For example, UDDI queries (or queries made of other directoryor registry systems) may be made by the web services accelerator andinformation obtained from UDDI registries (or other directory orregistry systems) may be processed by the web services acceleratorbefore it is transmitted to the mobile device.

In variant embodiments of the invention, instructions for performing thesteps of a method of processing a web service description in anembodiment of the invention may be stored on computer-readable media,which may include physical or transmission-type media, for example.

The invention has been described with regard to a number of embodiments.However, it will be understood by persons skilled in the art that othervariants and modifications may be made without departing from the scopeof the invention as defined in the claims appended hereto.

1. A method of processing a web service description so that said web service description is adapted for use with a mobile device, said web service description comprising a plurality of web service description elements, wherein said method is performed at a computing device remotely coupled to the mobile device, said method comprising: receiving a first web service description file comprising said web service description, wherein said web service description defines an interface to a web service; creating at least one accelerator output file from said web service description, said creating comprising optimizing said web service description for said mobile device; wherein said at least one accelerator output file comprises a second web service description file, said second web service description file comprising an optimized web service description adapted for processing by said mobile device; and transmitting said at least one accelerator output file to said mobile device, wherein said at least one accelerator output file facilitates invocations of said web service by said mobile device; wherein said optimizing comprises resolving symbolic references in said web service description of said first web service description file such that said at least one accelerator output file is parseable by said mobile device in one pass; and wherein said resolving comprises representing the plurality of web service description elements as nodes in a graph, re-ordering the nodes into a tree data structure so that said symbolic references are resolved in a forward direction, and creating said at least one accelerator output file from said tree data structure; wherein each of a subset of said plurality of web service description elements is associated with transport protocols not supported by said mobile device, and wherein said optimizing further comprises identifying said subset, and excluding said subset from said at least one accelerator output file.
 2. The method of claim 1, wherein both said web service description of said first web service description file and said optimized web service description of said second web service description file are in Web Service Description Language.
 3. The method of claim 1, wherein invocations of the web service by the mobile device are performed in accordance with a Simple Object Access Protocol.
 4. The method of claim 1, wherein said optimizing further comprises modifying one or more names associated with each of one or more web service description elements.
 5. The method of claim 1, further comprising validating said at least one accelerator output file.
 6. The method of claim 1, further comprising processing said at least one accelerator output file by identifying web service description elements that define inputs to said web service, a destination, and a format for said inputs from said optimized web service description.
 7. The method of claim 6, further comprising invoking said web service by transmitting input data to said destination in said format.
 8. The method of claim 7, further comprising receiving output data from said web service in response to said invoking.
 9. The method of claim 1, wherein said optimizing further comprises extracting invocation information from said web service description, and storing said invocation information.
 10. The method of claim 9, further comprising processing said at least one accelerator output file by identifying web service description elements that define inputs to said web service and obtaining operation parameters based on said inputs.
 11. The method of claim 10, further comprising generating input data by combining said operation parameters with said invocation information.
 12. The method of claim 11, further comprising invoking said web service by transmitting said input data to said web service.
 13. The method of claim 12, further comprising receiving output data from said web service in response to said invoking.
 14. The method of claim 1, wherein said at least one accelerator output file comprises code adapted for execution on said mobile device, for obtaining input data used to invoke said web service, and for invoking said web service using said input data.
 15. The method of claim 14, wherein said creating comprises: identifying web service description elements that define inputs to said web service from said web service description; producing first instructions for generating a user interface to prompt a user for one or more of said inputs to said web service; producing second instructions for obtaining input data associated with said one or more inputs; identifying web service description elements that define a destination and a format for said inputs to said web service; and producing third instructions for invoking said web service by transmitting said input data to said destination in said format.
 16. The method of claim 15, wherein said creating further comprises: identifying web service description elements that define outputs from said web service in response to invocations of said web service and a format for said outputs from said web service description; and producing fourth instructions for receiving output data in said format from said web service.
 17. The method of claim 16, wherein said creating further comprises: producing fifth instructions for outputting output data received from said web service to said user.
 18. The method of claim 14, wherein said creating further comprises compiling instructions produced at said creating into said code.
 19. The method of claim 18, wherein said code represents an executable Java application.
 20. The method of claim 14, further comprising processing said at least one accelerator output file by executing said code.
 21. A web services accelerator comprising a processor, which resides on a computing device in a network in which said computing device is coupled to a mobile device, wherein said processor is configured to perform a method of processing a web service description so that said web service description is adapted for use with said mobile device, said web service description comprising a plurality of web service description elements, said method comprising: receiving a first web service description file comprising said web service description, wherein said web service description defines an interface to a web service; creating at least one accelerator output file from said web service description, said creating comprising optimizing said web service description for said mobile device, wherein said at least one accelerator output file comprises a second web service description file, said second web service description file comprising an optimized web service description adapted for processing by said mobile device; and transmitting said at least one accelerator output file to said mobile device, wherein said at least one accelerator output file facilitates invocations of said web service by said mobile device; wherein said optimizing comprises resolving symbolic references in said web service description of said first web service description file such that said at least one accelerator output file is parseable by said mobile device in one pass; and wherein said resolving comprises representing the plurality of web service description elements as nodes in a graph, re-ordering the nodes into a tree data structure so that said symbolic references are resolved in a forward direction, and creating said at least one accelerator output file from said tree data structure; wherein each of a subset of said plurality of web service description elements is associated with transport protocols not supported by said mobile device, and wherein said optimizing further comprises identifying said subset, and excluding said subset from said at least one accelerator output file created at said creating.
 22. The web services accelerator comprising the processor of claim 21, wherein both said web service description of said first web service description file and said optimized web service description of said second web service description file are in Web Service Description Language.
 23. The web services accelerator comprising the processor of claim 21, wherein invocations of the web service by the mobile device are performed in accordance with a Simple Object Access Protocol.
 24. The web services accelerator comprising the processor of claim 21, wherein said optimizing further comprises modifying one or more names associated with each of one or more web service description elements.
 25. The web services accelerator comprising the processor of claim 21, wherein said method further comprises validating said at least one accelerator output file.
 26. The web services accelerator comprising the processor of claim 21, wherein said optimizing comprises extracting invocation information from said web service description, and storing said invocation information.
 27. The web services accelerator comprising the processor of claim 26, wherein said method further comprises obtaining operation parameters based on said inputs from said mobile device.
 28. The web services accelerator comprising the processor of claim 27, wherein said method further comprises generating input data by combining said operation parameters with said invocation information.
 29. The web services accelerator comprising the processor of claim 28, wherein said method further comprises invoking said web service by transmitting said input data to said web service.
 30. The web services accelerator comprising the processor of claim 29, wherein said method further comprises receiving output data from said web service in response to said invoking.
 31. The web services accelerator comprising the processor of claim 30, wherein said method further comprises transmitting at least a subset of said output data to said mobile device.
 32. The web services accelerator comprising the processor of claim 21, wherein said method further comprises receiving input data from said mobile device and invoking said web service by transmitting said input data to said web service.
 33. The web services accelerator comprising the processor of claim 32, wherein said method further comprises receiving output data from said web service in response to said invoking and transmitting said output data to said mobile device.
 34. The web services accelerator comprising the processor of claim 33, wherein said method further comprises detecting changes to said output data from said web service in response to said invoking and transmitting said changes to said mobile device.
 35. The web services accelerator comprising the processor of claim 21, wherein said at least one accelerator output file comprises code adapted for execution on said mobile device, wherein said code comprises instructions for obtaining input data used to invoke said web service, and for invoking said web service using said input data.
 36. The web services accelerator comprising the processor of claim 35, wherein said creating comprises: identifying web service description elements that define inputs to said web service from said web service description; producing first instructions for generating a user interface to prompt a user for one or more of said inputs to said web service; producing second instructions for obtaining input data for said one or more inputs; identifying web service description elements that define a destination and a format for said inputs to said web service; and producing third instructions for invoking said web service by transmitting input data to said destination in said format.
 37. The web services accelerator comprising the processor of claim 36, wherein said third instructions comprise instructions for receiving said input data from said mobile device and transmitting said input data to said web service.
 38. The web services accelerator comprising the processor of claim 37, wherein said creating further comprises: identifying web service description elements that define outputs from said web service in response to invocations of said web service and a format for said outputs from said web service description; and producing fourth instructions for receiving output data in said format from said web service.
 39. The web services accelerator comprising the processor of claim 38, wherein said creating further comprises: producing fifth instructions for outputting output data received from said web service to said user.
 40. The web services accelerator comprising the processor of claim 39, wherein said fifth instructions comprise instructions for receiving said output data from said web services and for transmitting said output data to said mobile device.
 41. The web services accelerator comprising the processor of claim 40, wherein said method further comprises detecting changes to said output data from said web service in response to said invoking and transmitting said changes to said mobile device.
 42. The web services accelerator comprising the processor of claim 29, wherein said creating further comprises compiling instructions produced at said creating into said code.
 43. The web services accelerator comprising the processor of claim 29, wherein said code represents an executable Java application.
 44. A storage media comprising program instructions which are executable at a computing device remotely coupled to a mobile device, to implement a method of processing a web service description so that said web service description is adapted for use with said mobile device, said web service description comprising a plurality of web service description elements, said method comprising: receiving a first web service description file comprising said web service description, wherein said web service description defines an interface to a web service; creating at least one accelerator output file from said web service description, said creating comprising optimizing said web service description for said mobile device, wherein said at least one accelerator output file comprises a second web service description file, said second web service description file comprising an optimized web service description adapted for processing by said mobile device; and transmitting said at least one accelerator output file to said mobile device, wherein said at least one accelerator output file facilitates invocations of said web service by said mobile device; wherein said optimizing comprises resolving symbolic references in said web service description of said first web service description file such that said at least one accelerator output file is parseable by said mobile device in one pass; and wherein said resolving comprises representing the plurality of web service description elements as nodes in a graph, re-ordering the nodes into a tree data structure so that said symbolic references are resolved in a forward direction, and creating said at least one accelerator output file from said tree data structure; wherein each of a subset of said plurality of web service description elements is associated with transport protocols not supported by said mobile device, and wherein said optimizing further comprises identifying said subset, and excluding said subset from said at least one accelerator output file. 